[2026-02-27] P4

🦥 본문

Background

OpenFlow : Control plane과 Data plane 사이를 연결하는 인터페이스. 기존에는 12개의 헤더 필드에서 매칭할 수 있는 단일 규칙 테이블이 존재. 하지만 패킷 처리 기술의 발달로 41개의 다단계 규칙 테이블이 추가되면서 복잡해지고 있음.

Motivation

1. 고정된 하드웨어 설계의 제약으로 인한 복잡성 및 유연성 부족

   • 헤더 필드의 추가와 다단계 규칙으로 사양의 복잡성이 증가.

     → 사양을 확장하는 대신 패킷을 파싱하고 헤더 필드를 매칭하는 유연한 매커니즘 지원

   • OpenFlow는 사전에 정해진 필드와 액션을 사용하여 패킷을 처리함

     → 특정 프로토콜 필드가 사전에 정해져 있지 않아도 프로그래머가 새로운 헤더 유형을 직접 선언하고 처리

2. 저수준 인터페이스

   • 칩의 제조사마다 고유한 프로그래밍 체계를 가지며 하드웨어와 처리 방식이 다름

     → 추상화를 통해 하드웨어에 신경 쓰지 않고 프로그래밍

Goal

1. 재설정 가능성 : 컨트롤러는 패킷 파싱 및 처리를 재정의할 수 있어서 유연한 매커니즘을 제공
2. 프로토콜 독립성
   • 스위치는 특정 패킷 형식에 얽매이지 않음
   • 컨트롤러는 특정 패킷 형식에 맞는 패킷 파서와 매치&액션 테이블의 집합을 지정
3. 타겟 독립성 : 프로그래머가 스위치의 세부 사항을 알 필요 없음. 컴파일러는 P4 코드를 스위치를 구성하는 데 사용되는 타겟 종속적인 프로그램으로 변환할 때 스위치의 기능을 고려.

FORWARDING MODEL

새로운 헤더를 정의할 수 있는 프로그래밍 가능한 파서 + 직렬 또는 병렬의 조합으로 배열된 여러 단계의 매치+액션 단계로 구성.

• 액션은 프로토콜 독립적. 또한 primitive들로 구성됨.
  • primitive : 더 이상 쪼갤 수 없는 최소 단위의 동작.
    • ex) 체크섬 계산, 필드 값 증감
• 다양한 패킷 전달 장치 및 처리 기술을 일반화하여 컴파일러가 다양한 장치에 매핑할 수 있는 타겟 독립적인 프로그램을 만듦
• Configure과 Populate에 의해 제어
  • Configure : 어떤 프로토콜이 지원되는 지와 스위치가 패킷을 처리하는 방법 결정
    • 파서를 프로그래밍
    • 매치+ 액션 단계의 순서 설정
    • 각 단계에서 처리되는 필드 지정
  • Populate : 특정 시점에 패킷에 적용되는 정책을 결정 **
    • Configuration 중에 지정된 매치+액션 테이블에 엔트리를 추가 및 제거
  • Configuration 단계. 즉 파이프라인을 설계하는 단계에서는 패킷을 처리할 필요가 없지만 실제 구현 시에는 설정을 바꾸는 중에도 중단 없이 패킷을 처리해야 재설정 목표에도 어긋나지 않음
    • 고정 기능 ASIC 스위치에서는 Configuration 단계가 의미가 없고 P4 프로그램을 지원하는 지만 확인

동작 흐름

1. 파서에 의해 패킷 처리
   • payload는 별도로 버퍼링되며 매칭에는 사용할 수 없음
   • 헤더에서 필드를 추출.
     • 파서는 프로그래머가 지정한 대로, 패킷을 자름. 잘라진 형태를 필드라고 함. 스위치는 매치+액션 시, 무슨 프로토콜인지 따지지 않고 필드를 규칙대로 비교하고 바꿈

2. 매치+액션 테이블은 ingress와 egress로 나뉨

   두 단계 모두 패킷 헤더를 수정할 수 있음

   • ingress match+action : 패킷이 나갈 출력 포트와 패킷이 배치될 큐를 결정
     • 패킷 전달, 복제(멀티캐스트, 스팬 또는 control plane 전송 용), 폐기되거나 flow control을 트리거
   • egress match+action : 패킷 헤더에 인스턴스별 수정을 수행
     • 예를 들어, 멀티캐스트 같이 하나의 패킷을 여러 포트로 나갈 때, 포트마다 조금씩 다르게 수정해야 할 부분을 처리
   • action table : 프레임 간 상태를 추적하기 위해 카운터, policers 등의 액션 테이블을 플로우와 연결
     • policer : 속도 제한을 추적
   • metadata 추가 : 패킷에 단계마다 추가 정보를 전달. 패킷 헤더 필드와 동일하게 취급
     • 예를 들어, ingress port, 전송 목적지 및 큐, 스케쥴링에 사용할 수 있는 timestamp, 가상 네트워크 식별자 등
   • Queueing : OpenFlow와 동일.
     • 액션이 패킷을 큐에 매핑. 큐의 스케쥴링은 configuration 단계에서 정해짐
       • 스케쥴링의 예시 : 최소 대역폭, DRR 등
   • Congestion control : 매치+액션 테이블을 사용하여 메커니즘 구현 가능
     • 예를 들어, ECN 비트 설정

A PROGRAMMING LANGUAGE

언어의 역할

1. 패킷 형식 선언 : 파서에게 헤더 유형 선언
   • 예를 들어, 앞 14바이트는 이더넷, 그 뒤에는 IP 헤더가 올 것이라고 구조를 정의
2. 패킷 헤더 처리 : 선언된 헤더 유형과 기본 액션 집합을 사용하여 헤더 필드 처리
   • 예를 들어, TTL 필드 감소, checksum 계산 등

기존 Click과의 비교

C++로 구성된 모듈을 통해 스위치를 구축하는 언어

• parse - match - action 파이프라인을 반영하지 않음
• controller-switch 구조를 위해 설계되지 않아서, 동적으로 populated match+action 테이블을 기술하는 것이 불가
• 병렬 처리를 위한 의존성 파악이 힘듦

  • TDG (테이블 의존성 그래프) : 의존성을 식별할 수 있는 그래프

    

    • 필드 입력, 액션, 그리고 테이블 간의 제어 흐름을 기술
    • 노드들은 매치+액션 테이블에 직접 매핑되며, 의존성 분석을 통해 각 테이블이 파이프라인의 어디에 위치할 수 있는지 식별
    • 프로그래머가 기존 C++ 기반의 Click으로는 TDG를 생각하기는 어려움

P4의 컴파일 프로세스

1. 제어 흐름을 나타내는 P4를 통해 프로그램을 짬
2. 코드를 분석하여 TDG로 번역한 후 TDG를 특정 스위치의 타겟 후 매핑

P4 LANGUAGE BY EXAMPLE

Background

네트워크는 End-host와 직접 연결되는 Edge와 edge들과 연결된 core가 있음. End-host가 많아지면서 core의 L2 테이블(스위치들이 기억해야 할 주소)가 넘침

• 기존 해결책
  • MPLS : 여러 태그를 사용하는 레이블 분배 프로토콜을 구현이 어려움
  • PortLand : MAC 주소를 다시 써야하므로 기존 네트워크 디버깅 도구를 망가뜨릴 가능성. ARP 요청에 응답할 새로운 에이전트가 필요
• P4의 mTag : 32비트 태그. src 경로 또는 destination locator이 담김
  1. 패킷이 첫 번째 ToR 스위치에 들어올 때 32비트 태그를 붙임
     • End-host의 NIC에서도 추가 가능
  2. 코어 스위치는 태그의 1 바이트만 검사하여 스위칭

P4 Concepts

• 헤더 정의 : 일련의 필드들의 순서와 구조를 기술. 필드의 너비 지정과 필드 값 범위에 대한 제약이나 가변 크기 필드의 최대 길이 설정

  • Ex) 표준 이더넷과 VLAN 헤더

      header ethernet {
        fields {
          dst_addr : 48; // width in bits
          src_addr : 48;
          ethertype : 16;
        }
      }
            
      header vlan {
        fields {
          pcp : 3;
          cfi : 1;
          vid : 12;
          ethertype : 16;
        }
      }
    

  • mTag : 기존의 선언을 변경하지 않고도 추가. 필드 이름을 보면, 코어가 두 단계의 aggregation layer로 구성되어 있음을 알 수 있음

    • 스위치는 위치(1단계 스위치인지 2단계 스위치인지)와 패킷 이동 방향(패킷이 상행인지 하행인지)에 따라 바이트를 검사

      header mTag {
        fields {
          up1 : 8;
          up2 : 8;
          down1 : 8;
          down2 : 8;
          ethertype : 16;
        }
      } 
    

• 파서 정의 : 패킷 내에서 헤더와 유효한 헤더 시퀀스를 식별하는 방법을 지정
  1. 상태 머신 방식 : 패킷의 시작-끝까지 탐색하여 헤더를 하나 씩 추출. 추출된 값은 매치+액션 테이블로 이동
  2. 전이 : 다음 헤더로 이동. 현재 헤더의 값에 의해 트리거
     • EX) mTag

      parser start {
        ethernet; [cite: 285, 287]
      }
             
      parser ethernet {
        switch(ethertype) {
          case 0x8100: vlan; [cite: 288, 289, 292]
          case 0x9100: vlan; [cite: 293]
          case 0x800: ipv4; [cite: 294]
          // Other cases
        }
      }
             
      parser vlan {
        switch(ethertype) {
          case 0xaaaa: mTag; [cite: 308, 309, 312]
          case 0x800: ipv4; [cite: 313]
          // Other cases
        }
      }
             
      parser mTag {
        switch(ethertype) {
          case 0x800: ipv4; [cite: 315, 316, 317]
          // Other cases
        }
      }
     

  • 파싱은 start 상태에서 시작하여 stop이나 에러 상황까지 진행. 새로운 헤더를 위한 상태에 도달하면 상태머신은 specification을 사용하여 헤더를 추출하고 전이. mTag를 위한 파서는 단순
• 테이블 매치 : 테이블이 매칭할 수 있는 필드와 테이블이 실행할 수 있는 액션을 정의

  • 예를 들어, mTag에서 에지 스위치는 L2 destination 주소와 VLAN ID를 매칭하고 헤더에 추가할 mTag를 수행

      table mTag_table {
        reads {
          ethernet.dst_addr : exact;
          vlan.vid : exact;
        }
        actions {
          // At runtime, entries are programmed with params
          // for the mTag action. See below.
          add_mTag;
        }
        max_size : 20000;
      }
    

    • reads : 매치 유형 (exact, ternary 등)에 따라 제한된, 매칭할 필드를 선언
    • actions : 패킷에 적용될 수 있는 가능한 액션들을 나열
    • max_size : 테이블이 지원해야 하는 엔트리수를 지정.
  • 컴파일러가 테이블 사양을 보고 메모리 유형(TCAM, SRAM)과 메모리 양을 결정

  • ex) 제어 프로그램에서 사용되는 테이블의 정의 맛보기

      table source_check {
        // Verify mtag only on ports to the core
        reads {
          mtag : valid; // Was mtag parsed?
          metadata.ingress_port : exact;
        }
        actions { // Each table entry specifies *one* action
          // If inappropriate mTag, send to CPU
          fault_to_cpu;
          // If mtag found, strip and record in metadata
          strip_mtag;
          // Otherwise, allow the packet to continue
          pass;
        }
        max_size : 64; // One rule per port
      }
            
      table local_switching {
        // Reads destination and checks if local
        // If miss occurs, goto mtag table.
      }
            
      table egress_check {
        // Verify egress is resolved
        // Do not retag packets received with tag
        // Reads egress and whether packet was mTagged
      }
    

• 액션 : 단순하고 프로토콜 독립적인 primitive들로 복잡한 액션을 구성하여 액션 함수 세트를 선언
  • 액션 함수들은 사양 정의와 엔트리 추가 과정을 단순화.
  • P4는 액션 함수 내의 primitive들이 병렬로 실행된다고 가정.
    • 병렬 실행이 불가능한 스위치는 에뮬레이션을 통해 구현
      • 에뮬레이션 : 소프트웨어나 논리적인 트릭을 사용하여 그 기능이 있는 것처럼 똑같이 흉내내는 것

  • EX) add_mTag 액션

      action add_mTag(up1, up2, down1, down2, egr_spec) {
        add_header(mTag);
        // Copy VLAN ethertype to mTag 
        copy_field(mTag.ethertype, vlan.ethertype);
        // Set VLAN’s ethertype to signal mTag
        set_field(vlan.ethertype, 0xaaaa);
        set_field(mTag.up1, up1);
        set_field(mTag.up2, up2);
        set_field(mTag.down1, down1);
        set_field(mTag.down2, down2);
        // Set the destination egress port as well
        set_field(metadata.egress_spec, egr_spec);
      }
            
    

    • 액션에 매개변수는 런타임에 매치 테이블로부터 제공
    • 위의 기능은 VLAN 태그 뒤에 mTag를 삽입하고 다음에 오는 내용을 나타내기 위해 VLAN 태그의 Ethertype을 mTag로 복사하며 mTag임을 신호하기 위해 VLAN 태그의 0xaaaa로 설정
    • 패킷에서 mTag를 제거하는 역방향 액션 사양과 에지 스위치에서 이 액션을 적용하는 테이블은 안 썼음
  • primitive actions
    • set field : 헤더의 특정 필드를 특정 값으로 설정. 마스크 설정이 지원.
    • copy field : 한 필드를 다른 필드로 복사.
    • add header : 특정 헤더 인스턴스와 그 모든 필드를 유효한 상태로 설정.
    • remove header : 패킷에서 헤더와 그 모든 필드를 삭제(pop).
    • increment : 필드의 값을 증가시키거나 감소.
    • checksum : IPv4 체크섬과 같이 일부 헤더 필드 집합에 대한 체크섬을 계산.
• 제어 프로그램 : 매치+액션 테이블의 순서를 결정. 단순한 명령형 프로그램이 매치+액션 테이블 간의 제어 흐름을 기술
  • 함수, 조건문, 테이블 참조의 집합을 통해 제어 흐름을 지정

  • mTag 구현

    

    1. 파싱 후 source_check 테이블에서 수신된 패킷과 인그레스 포트 사이의 일관성 검증
       • mTag는 코어 스위치의 연결된 포트에서만 보이게 됨
       • mTag를 제거하고 있었는지 여부를 메타데이터에 기록.
         • 이 후 테이블이 태그를 붙이는 것을 방지하기 위해 매칭에 사용
    2. local_switching 테이블
       • miss가 발생하면 패킷의 목적지가 로컬로 연결된 호스트가 아님
         • mTag_table이 적용
       • 로컬로 가든 (hit), Core로 가든(miss) egress_check 테이블 적용
         • 만약 목적지를 알 수 없는 경우 SDN controller에게 알림을 보냄 - 코드

      control main() {
        // Verify mTag state and port are consistent
        table(source_check);
              
        // If no error from source_check, continue
        if (!defined(metadata.ingress_error)) {
          // Attempt to switch to end hosts
          table(local_switching);
                
          if (!defined(metadata.egress_spec)) {
            // Not a known local host; try mtagging
            table(mTag_table);
          }
                
          // Check for unknown egress state or
          // bad retagging with mTag.
          table(egress_check);
        }
      }
    

Compiling A P4 Program

Compiling Packet Parsers

• 프로그래밍 가능한 파서가 있는 경우, 프로그래머 코드을 통해 파싱 상태 머신으로 만듦
• 고정된 파서의 경우, 코드가 실제 장비의 사양이 일치하는지만 확인

• 파서의 VLAN 및 mTag 섹션에 대한 상태 테이블 엔트리

  

  • 현재 상태, 매칭할 필드 값, 다음 상태를 지정

Compiling Control Programs

제어 프로그램 분석을 통해 의존성을 식별하며 헤더 필드를 병렬로 처리. 컴파일러는 스위치를 위한 타겟 configuration을 생성

타겟에 따른 프로세스

기본적으로 2단계 컴파일 프로세스 ( 코드를 TDG로 바꾼 후 의존성 확인. 장비에 맞춰 배치 )를 따름

• 소프트웨어 스위치
  • 특징 : 테이블 수, 테이블 구성 및 파싱이 소프트웨어를 통해 제어하여 유연함
  • 방식 : mTag TDG를 테이블에 그대로 매핑. 테이블 유형 정보를 사용하여 테이블의 너비, 높이 및 매칭 기준(예: exact, prefix 또는 wildcard)을 제한. 소프트웨어 데이터 구조를 활용하여 ternary 또는 prefix 매칭을 최적화
• RAM&TCAM을 가진 하드웨어 스위치
  • 방식
    • mTag 테이블에 대해 RAM을 사용하여 Hashing 기반 정확도 매칭을 수행.
    • 태그 일부만 매칭하는 코어 mTag 포워딩 테이블은 TCAM에 매핑
• 병렬 테이블을 지원한느 스위치
  • 방식 : 컴파일러가 의존성을 감지하여 테이블을 병렬 또는 직렬로 배치
    • 예를 들어, mTag_table과 local_switching 테이블은 의존성이 없으므로 병렬로 실행
• 파이프라인 끝에서 액션을 적용하는 스위치
  • 방식 : 컴파일러가 중간 단계에서 최종 쓰기에 사용될 메타 데이터를 생성하도록 지시
• 적은 수의 테이블을 가진 스위치
  • 방식 : 컴파일러는 다수의 P4 테이블을 더 적은 수의 물리적 테이블로 매핑. 컨트롤러가 런타임에 새로운 규칙을 설치할 때, 컴파일러의 규칙 변환기는 두 P4 테이블의 규칙을 합성하여 단일 물리적 테이블을 위한 규칙을 생성
    • 예를 들어, local_switching은 mTag 테이블과 통합

Conclusion

• OpenFlow의 한계 : 미리 정해진 헤더와 액션만 사용할 수 있는 고정 기능 스위치를 대상으로 하기에 유연성 부족
• Data plane 제어 : 코드 → TDG → 타겟 스위치에 매핑
• 현재는 패킷 처리 방식에 집중하고 있으며 혼잡 제어, 큐잉, 트래픽 모니터링 등 세부적 측면은 과제로 남음